Questions
9 of 11
1Evaluate this claim: 'Cosine similarity and normalized dot product always produce identical rankings.' What subtlety do candidates often miss here?
2Many candidates assume increasing ef at query time always improves recall with only a linear latency cost. What's misleading about that assumption?
3Why is 'just add more RAM' not always a valid answer to a Qdrant performance question in a system design interview?
4A candidate claims that quantization always speeds up search. Under what conditions might quantization with rescoring actually be slower than searching un-quantized vectors?
5Why can two identical-looking filter queries - one using an indexed field, one using an equivalent but unindexed field - have wildly different performance, even though they return the same results?
6At billion-point scale, how would your indexing and sharding strategy differ from a design that works fine at ten million points?
7How would you architect a system to gracefully degrade - rather than fail outright - when a burst of traffic exceeds provisioned Qdrant capacity?
8What are the limits of a purely payload-filter-based multitenancy model, and at what point would you need to introduce dedicated shards or collections per tenant instead?
9How would you approach re-embedding a multi-billion-point production collection with a new embedding model with zero search downtime?
10When designing a retrieval system that combines dense, sparse, and multivector reranking at extreme scale, what's the single biggest cost driver you'd optimize first, and why?
11If you were asked to design Qdrant's filtered-HNSW search from scratch, what core problem would you need to solve, and what naive approach would you reject first?
QdrantQdrant
Core Concepts
Setup and Basic Use
QueryAPIs
Named Vectors and Multitenancy
Sparse Vectors and Hybrid Search
Snapshots and Backups
Indexing Internals
Internal Architecture
Performance and Optimisation
Security
Error Handling and Debugging
Testing
Design Patterns
Implementation Scenarios
System Design and Scalability
Edge Cases
09 / 11

How would you approach re-embedding a multi-billion-point production collection with a new embedding model with zero search downtime?

Shadow collection, dual-write, incremental backfill, controlled cutover

Re-embedding a multi-billion-point collection is a multi-week project, and zero downtime requires a shadow collection that is populated in parallel with the live one. The pattern is: create the shadow collection with the new model's dimension and metric; dual-write new and updated points to both collections; backfill the existing points into the shadow collection by re-embedding them in batches; monitor progress and validate recall; cut over the query path to the shadow collection via an alias; keep the old collection for rollback. The backfill is the long pole: re-embedding a billion points takes a significant amount of GPU time and Qdrant write throughput, and it must be paced so it does not saturate the resources that the live collection needs. The dual-write ensures that points written during the backfill are present in both collections, and the backfill ensures that the historical points are present in the shadow collection. The cutover is a metadata operation (alias move) and can be rolled back quickly if the new model does not perform as expected.

The mechanism that makes zero downtime possible is that the live and shadow collections are independent, and the query path uses exactly one of them at a time. During the migration, the live collection serves all queries and the shadow collection is being populated. New writes go to both, so the shadow collection does not fall behind. The backfill processes the historical data in batches, which can be paused and resumed. The migration state is always consistent from the query path's perspective: it uses the live collection until the cutover, then the shadow collection. The cutover is atomic at the alias level, and the rollback is the reverse alias move. The main risks are: (1) the dual-write failing silently, so some points are missing from the shadow collection; (2) the backfill not completing before the cutover, so some points are missing; (3) the new model performing worse than the old one, which is why validation before cutover is essential; (4) the cutover causing a performance regression, which is why the shadow collection should be sized and configured to meet the SLO. The validation should include recall against a held-out set, ranking comparison with the old collection, and a load test of the shadow collection at production QPS.

  1. 1

    Shadow collection: new dimension and metric, populated in parallel.

  2. 2

    Dual-write: new and updated points go to both collections.

  3. 3

    Backfill: re-embed historical points in batches, paced to avoid saturating resources.

  4. 4

    Progress tracking: know when the backfill is complete before cutover.

  5. 5

    Validation: recall against a held-out set, ranking comparison, load test.

  6. 6

    Cutover: alias move, atomic and reversible.

  7. 7

    Rollback: keep the old collection until the new one is proven.

  8. 8

    Monitoring: dual-write success rate, backfill progress, validation metrics.

The trade-off is between the cost of running two collections during the migration and the safety of zero downtime. The shadow collection doubles the storage and the write throughput during the migration, and the backfill consumes GPU and Qdrant write capacity. The alternative - an in-place migration - is not possible because the dimension and metric are immutable, and even if it were, it would cause downtime and mixing of vector spaces. The common mistakes are: (1) cutting over before the backfill is complete; (2) not monitoring the dual-write, so the shadow collection is missing points; (3) not validating the new model's recall before cutover; (4) deleting the old collection immediately after cutover, leaving no rollback; (5) not pacing the backfill, so it saturates the live collection's resources. Version note: the shadow collection pattern is version-independent, but the alias API and the collection creation API have evolved across Qdrant releases. The exact shape of the alias operations and the multi-vector configuration may differ. Verify on your version.

javascript

Version-dependent: the alias API, the collection creation API, and the scroll API have evolved across Qdrant releases. The exact shape of the alias operations may differ. Verify on your version.

Difficulty: 9/10
Topics: Migration, Embedding Models, Zero Downtime

Scenario Questions

0-2 years experience
  1. 1

    You need to switch embedding models on a large collection. Explain why you cannot do it in place and what you would do instead.

  2. 2

    A teammate cuts over before the backfill is complete. Explain the consequence and how to prevent it.

2-5 years experience
  1. 1

    You are halfway through a billion-point backfill and the live collection's latency is degrading. Diagnose the cause and propose a fix.

  2. 2

    You cut over and discover a recall regression. Describe the rollback and the investigation.

5-8 years experience
  1. 1

    Design the full migration plan for a multi-billion-point collection, including the dual-write, backfill pacing, validation, cutover, and rollback.

  2. 2

    You need to validate the new model before cutover without affecting the live system. Describe the shadow evaluation.

8+ years experience
  1. 1

    Derive the timeline for a billion-point migration as a function of embedding throughput, write throughput, and validation time. How would you compress it?

  2. 2

    You are designing a system that supports frequent model upgrades (quarterly). Describe the migration infrastructure that makes this routine.

Follow-up Questions

  • ❓How would you pace the backfill so it does not saturate the live collection's resources?
  • ❓If the new model's recall is worse than the old one's on a subset of queries, how would you decide whether to cut over?